Securing a software program against malicious attacks can represent a significant difficulty. For example, the program can include different vulnerabilities in relation to different data types and ways in which those data types may be implemented. Malicious attackers may exploit these vulnerabilities to manipulate data values. This malicious manipulation can result in unintended actions by the program such as runtime errors, data destruction, data exposure, and so on. In general, the attacks focus on exploiting buffer overflows or other vulnerabilities associated with control data and/or non-control data to modify a return address, a function pointer, or some other security sensitive data.
Moreover, ensuring that a program conforms to desired standards in relation to formatting, security, and other standards to prevent these malicious attacks can be a significant difficulty especially when a program is relatively robust and/or complex. In general, developers may reference control flow graphs and/or other tools in attempts to optimize a program and/or to better understand relationships between different functions/segments within the program. However, present approaches produce large complex graphs that can be impractical for a developer to interpret and are not generally available in a timely manner so as to be useful when originally generating the program.
Similarly, adding instrumentation into the source code of the program to provide security against the malicious attacks can further complicate development. For example, additional source code embodied as the instrumentation may be inaccurately coded or may be unintentionally left out considering the many varied segments of instrumentation that are generally to be included within the program and subsequently verified. Consequently, securing the program flow and/or non-control data arguments may suffer from inadequate instrumentation leading to further difficulties such as security holes, which open the program to further malicious attacks.